-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf: fix cpu usage in cache #626
Conversation
e6dc7fe
to
cce3198
Compare
…s serialization/deserialization on each call to cache +ts refactoring
cce3198
to
277973e
Compare
I've briefly reviewed this PR while it was in draft. Could u please elaborate on the reason of leakage? |
Took flame chart during a load test to the local ILC server connected to the production registry (see attached file) in the jira ticket. |
ilc/common/MemoryCacheStorage.ts
Outdated
@@ -0,0 +1,12 @@ | |||
import { CacheResult, CacheStorage } from './types/CacheWrapper'; | |||
|
|||
export class MemoryCacheStorage implements CacheStorage { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we do not limit cache in any way it might lead to memory leak during long-running processes. I suggest that instead we create EvictingCacheStorage
based on some sort of LRU algorithm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wRLSS Despite the fact that your comment is 100% valid, I'd suggest addressing it within the scope of another task because, as far as I can see, the approach to storing items in memory hasn't changed. This PR simply removes serialization/deserialization, so it won't make things any worse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the change is not that big and since we are fine-tuning ILC it can be done, small class update based on gpt suggestion without large impact. But I'm fine doing this in other PR, up to @stas-nc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can do it, but was not sure, because we have some kind of pre-heat logic, in this case, if the ilc server is idle we are losing it's benefit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can do it, but was not sure, because we have some kind of pre-heat logic, in this case, if the ilc server is idle we are losing it's benefit.
It is possible to do evicting focused on number of usage rather than time so idleness won't affect it. Anyways, approving this PR, but I think we should check this case
…r plugin Additionally fixed system js file, because banner plugin evaluates placeholders like [id] [name] etc.
Coverage ReportIlc/serverCommit SHA:465669aabbe64bba827c648a3e9af30f54554b85 Test coverage results 🧪
File details
Ilc/clientCommit SHA:465669aabbe64bba827c648a3e9af30f54554b85 Test coverage results 🧪
File details
RegistryCommit SHA:465669aabbe64bba827c648a3e9af30f54554b85 Test coverage results 🧪
File details
|
No description provided.